iT邦幫忙

2025 iThome 鐵人賽

DAY 1
0

從Keycloak建立SSO服務開始

上一次參加iT鐵人賽是2022年,也就是有兩年沒參賽。
但這次的主題緣起,其實可以從2021年的參賽主題「用Keycloak學習身份驗證與授權」開始說起。

在寫完該主題後,便在公司開始引進Keycloak作爲單點登入服務(Single Sign-On,SSO)。也就是說,開始在公司維運使用Keycloak也就3年多了,從最開始的16.1.1版本,分四個區域建立四組服務,到跳板升級到22.0.5,並合併四個資料區域提供一組服務。到現在最新版本都已經到26版,並且Keycloak也早已進入的雲原生計算基金會(Cloud Native Computing Foundation,CNCF)的孵化項目

除了資料區的合併,還有一項變化是:將原本在前方作為負載平衡,反向代理Keycloak的Nginx換成了APISIX。

DoS服務阻斷到APISIX

爲什麼會選APISIX? 其實也沒什麼太大理由。

公司內另一項服務,因爲客戶端的錯誤設置,導致該服務最終資料庫無法負荷交易,造成類似DoS問題。

因此開始和同仁討論與尋找其他監控服務與防範做法。在此前,曾經聽過微服務概念中API Gateway提供的斷路器功能,也就是當服務開始發生問題後,不再接受新的請求,好讓服務有時間好好消化處理原本已接受的請求。

APISIX並不是唯一一個提供這樣服務的,起初也有考慮過Traefik、Kong、Tyk甚至envoy。不過Kong、Tyk屬於免費增值;envoy有點太過複雜;Traefik很有意思,單當時資源不太多。而APISIX已經是Apache基金會下的頂級項目(Top-Level Project),使用友善Apache授權。不管是個人興趣和學習上容易性,還是當時相對豐富的中文資源(貢獻至Apache前,項目有華人發起),最開始嘗試API網關就直接從APISIX開始,也就沒有進一步嘗試其他備選項目。

總之,這次的主題會圍繞著APISIX的應用情境與功能進行分享,同樣也是做為一種個人學習記錄。


下一篇
序幕 - Keycloak實際部署架構
系列文
與雲原生精靈共舞:APISIX使用者的兩年旅程4
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言